The present invention relates in general to cellular communication technologies and in particular to methods of transmitting a message to a message server in a push-to-talk network.
Mobile cellular communication is evolving beyond traditional voice telephony towards more sophisticated services, such as Push-To-Talk (PTT). Similar to conventional walkie-talkie communication, PTT enables mobile communication users to send a voice message to one or more recipients over a mobile phone by simply pushing a key (i.e., PTT button, etc.).
One particular version of PTT, called PoC (PTT-over-Cellular), has started to be implemented in wireless data networks such as GSM/GPRS and CDMA cellular networks. By using internet protocols (i.e., an internet protocol network), these networks can provide a packet-based data service that enables information to be sent and received across a mobile telephone network. In addition, the use of internet protocols also facilitates PoC through the use of instant connections. That is, information can be sent or received immediately as the need arises, subject to available time slots at the air interface.
PTT, including PoC-based PTT, is also half-duplex. That is, all participants typically use a single frequency or channel for both transmission and reception. Either a participant speaks or listens, but not both. This is in contrast to traditional cellular communication that is full-duplex (e.g., like a regular wired phone), in which at least one channel or frequency is assigned to talk, and another separate one is assigned to listen such that both speaking and listening can occur simultaneously.
Many PTT implementations, including the PoC based PTT implementation, also provide contact list functionality. A contact list typically contains the identifiers of other users or groups such that an end user may initiate a PTT call by selecting one or more entries from the list. An entry in a contact list is a contact, e.g. the identity of a user, or a group, which is representative of multiple users. Within PoC, a contact list contains either users or groups, but not both. Generally, a contact is uniquely identified via a SIP URI (Session Initiation Protocol Universal Resource Identifier).
The PTT operator (i.e., Cingular, ATT, etc.) generally assigns to each user, an address-of-record (also known as public user identity) in the form of a SIP URI comprising a user name portion and a domain portion. In general, the username portion of the SIP URI uniquely identifies the user within a given namespace or network. Likewise, the domain part of the SIP URI uniquely identifies a domain owned by the operator. For example, “sip:joe.doe@operator.net” in which “joe.doe” is the username portion of the SIP URI and “operator.net” is the domain portion of the SIP URI. Additional information may also be associated with a contact to facilitate interaction with the contact list; for example, a display name.
PoC is discussed in greater detail in the following technical specifications which are incorporated by reference: Push-to-talk over Cellular (PoC); Architecture; PoC Release 2.0, V2.0.8 (2004-06) and Push-to-talk over Cellular (PoC); Signaling Flows—UE to Network Interface (UNI); PoC Release 2.0, V2.0.6 (2004-06) as well as Push-to-talk over Cellular (PoC) User Plane; Transport Protocols, PoC Release 2.0, V2.0.8 (2004-06). It should also be mentioned that a Release 1.0 is also available from the PoC Consortium as well as an upcoming PoC standard from Open Mobile Alliance (OMA). All of these are generally considered native PoC standards. Subsequently, a UE (user equipment) supporting either of these standards is called a native PoC client (or non-DVM client).
Referring now to FIG. 1, a simplified diagram of a PTT architecture is shown. In general, access in the PTT architecture may include both the radio access as well as other IP-enabled transport mechanisms (e.g. a PTT application client be hosted on an Internet-enabled PC). UE 102 generally refers to the device containing the PTT application client software, such as a cellular phone. Within the PoC architecture, UE 102 uses SIP to establish, modify and terminate multimedia sessions or calls with other PoC enabled clients. A session is considered an exchange of data between associations of participants. SIP supports session control, and may support user location, user capability, call setup, and call handling. In addition, since SIP is a generic session protocol, services other than voice can be chosen such as video transfer, multi-media messaging, multiparty gaming, etc.
Generally, an XML based extension associated with SIP messages, called SDP, is used to negotiate the appropriate level and type of service (i.e., available codecs, buffer sizes, etc.), as well as establish a transport path from UE 102 to PoC Server 110. The term early session refers to a session that is already available for quick connection establishment, prior to the PTT transmission (i.e., pre-established). The term on demand session generally refers to a session that is established as part of the PTT transmission. The type of session is normally configured by the operator as a service option choice. Early sessions connect faster but require more network resources.
Once the session is established, RTP (real time transmission protocol) is used for the transmission of data packets within a session. Because the PTT system is half-duplex, it is important to manage which participant within a session is permitted to speak (given that only one participant may speak at once). RTCP (RTP control protocol) is used to manage these permissions through a Talker Arbitration (TA) function commonly referred to as “floor control. Floor control is the process used to determine which participant receives permission to transmit by being granted the “floor.” A floor request results from a participant in a PTT session asking permission to transmit (e.g. by pressing the PTT button on the side of a device); such permission is typically provided if no other participant has already been granted the floor.
A floor release is an indication from a speaking user that they have finished speaking (e.g. by releasing the PTT button on the side of the device). A floor grant, one possible response to a floor request, informs the requesting participant that the floor has been granted. A floor idle, a response to a floor release, informs participants that the floor is idle (i.e. that a speaking user is no longer speaking and that the floor is now generally available). A floor deny, a second possible response to a floor request, informs the requesting participant that the floor request is denied (e.g. because another user has already been granted the floor). A floor taken, sent simultaneous with a floor grant, informs all participants that the floor has been granted to the indicated participant. Floor revoke removes the permission to transmit from a user who has previously been granted the floor. RTCP BYE indicates that the sending party wants to terminate the ongoing media session in current communication context, without changing the SIP-session state.
RTCP also facilitates maintenance of quality by providing talk burst quality feedback. This feedback reports the amount of media received by UE 102, which can be compared to the amount sent by the PoC server such that a discrepancy can indicate poor network conditions that may require engagement of various compensation algorithms.
In this diagram, UE 102 may be coupled to IMS 106 (IP Multimedia Sybsystem) through access network 104 which may include both radio and non-radio types of access (i.e., UTRAN, POTS, etc.). IMS provides routing, authentication and compression services to all SIP-based applications including PoC.
GLMS 108 (Group and List Management Server) commonly manages groups, contact lists and access lists. A contact list is a kind of address book that may be used by PTT users to establish an instant talk session with other PTT users or PTT Groups and to access PTT presence information. A user may have one or several contact lists containing either identities of other PTT users or PTT Groups. Contact list management includes operations to allow the UE 102 to store, modify, retrieve and delete the contact lists located in the GLMS 108, commonly through group list management protocols, such as HTTP/XML, XCAP, etc.
In general, an end user may select a group from the contact list to initiate an instant group talk session, or a chat group talk session, depending on the type of the group. A PTT access list is used by the end user as a means of controlling who is allowed to initiate instant talk sessions to the end user and who is allowed to receive PTT presence information for a user. Access lists contains end user defined identities of other PTT end users or groups, and include a blocked identities list and a granted identities list. Presence server 112 manages presence information and generally includes a status as to whether UE 102 is online (connected to the network) and PTT available (not already busy and ready to join a session).
OTAP (Over The Air Provisioning Server) 114 generally provides all the needed configuration parameters from the service provider network for a PTT Client, and sends a WAP-push/SMS containing a binary coded XML to every client UE with default factory and network settings.
Referring now to FIG. 2, a simplified diagram of an early session early media with auto-answer mode set is shown. As previously described, the term early session generally refers to a session that is established as part of the PTT transmission, just before the invitation of other participants.
Early media normally refers to the initial transmission of a talk burst (media) prior to the completion of service negotiation and transport path establishment. That is, the sending user may transmit voice prior to the completion of a connection to any other participant. Auto-answer mode allows a UE 102 to automatically establish a session without user (i.e., participant) input. In this example, UE A 102a is a client of PoC Server A 110a, while UE B 102b is a client of PoC Server B 110b. In addition, one of the PoC Server (in this case PoC Server A) also functions as a Controlling PoC Server, managing the overall communications between UE A 102a and UE B 102b. 
Initially, UE A 102a requests that a session be established by transmitting a SIP REFER message to PoC Server A 110a. That is, a user presses the PTT button on UE A 102a. Once received, a SIP 202 Accepted message is returned. PoC Server A 110a then sends a SIP INVITE request to the PoC Server B 110b. 
A SIP 200 OK response, establishing early media in auto-mode, is immediately sent back to PoC Server A 110a by PoC Server B 110b. A floor granted message is then send to UE A 102a, and a floor taken message is sent to UE B 102b. UE A 102a can now transmit an initial (i.e., first) talk burst of media.
PoC Server A 110a also transmits a SIP ACK message to PoC Server B 110b informing it of the started media transmission. A SIP NOTIFY message is also sent to UE A 102a to inform it that UE B 102b has now accepted the connection. UE A 102A responds by sending a SIP 200 OK message. Subsequently, the PTT transmission continues until the PTT button is released.
Referring now to FIG. 3, a simplified diagram of an early session with late media with manual-answer mode set is shown. Late media normally refers to the transmission of media after the completion of service negotiation and transport path establishment. Manual-answer mode requires a user (i.e., participant) to accept the establishment of a session to UE 102b prior to sending SIP 200 OK back to the originating party. As before, UE A 102a is a client of PoCS A 110a, while UE B 102b is a client of PoCS B 110b. 
Initially, UE A 102a requests that a session be established by transmitting a SIP REFER message to PoC Server A 110a. That is, a user presses the PTT button on UE A 102a. Once received, a SIP 202 Accepted message is returned. PoC Server A 110a then sends a SIP INVITE request to the PoC Server B 110b. 
A SIP 180 Ringing response is sent by UE B 102b to PoC Server B 102b. PoC Server B 110b forwards the SIP 180 Ringing response to PoC Server A 110a. When UE B 102B answers (i.e., user accepts the establishment of the session) a SIP 200 OK is immediately sent back to the PoC Server B 110b. 
The SIP 200 OK response is then forwarded to PoC Server A 110a by PoC Server B 110b. A floor granted message is then sent to UE A 102a, and a floor taken message is sent to UE B 102b. UE A 102a can now transmit an initial (i.e., first) talk burst of media.
PoC Server A 110a also transmits a SIP ACK message to PoC Server B 110b informing it of the media transmission. A SIP NOTIFY message is also sent to UE A 102a to inform it that UE B 102b has accepted the connection. UE A 102A responds by sending a SIP 200 OK message to PoC Server A 110a, which subsequently transmits an ACK message to UE B 102b. The PTT transmission continues until the PTT button is released.
However, although PTT may provide an easy-to-use, fast, and flexible form of voice communication, PTT is also limited in that it requires a participant to be available and online at the time of the PTT session. There is currently no way to transmit a message to an unavailable participant, for later retrieval, without first accessing the traditional cellular network to leave a regular voice mail using full-duplex radio channel.
In view of the foregoing, there are desired methods of transmitting a message to a message server in a push-to-talk network